In modern computer systems, especially those using a PC or laptop computer, it is common for the data stored in, for example, disk memory to be encrypted. This offers the user great protection against the stored data being discoverable by a thief--even when the computer is stolen.
Typically, such stored the information is encrypted with a key which is derived in some fashion from a password known only to the user. The password is converted via well known cryptographic processing techniques into a cryptographic key, which is used to decrypt (and thereby access) all information stored in the computer.
Particularly if sensitive data is being stored, most standard security practices urge users not to record passwords--lest they be discovered by an adversary. Since the data stored in the computer is present only in its encrypted form, without knowledge of the password, it is, for all practical purposes, inaccessible. Accordingly, a serious problem is created if the user forgets the password.
In practice, from time to time users do forget their passwords. The problem is compounded by the possibility that a disgruntled employee may refuse to supply or "forget" the password to a corporate computer which has previously been assigned to the employee.
One attempted solution to this problem is to "escrow" the password (or some other key information associated with the encryption) with a trustee, i.e., a trusted entity, such as, for example, a computer security software officer in the user's organization. The user may use the trustee's public key to encrypt the secret information and store the information in, for example, with the trustee, with a 3rd party or with the protected computer itself. In this fashion, the trustee could, in case of emergency, be given the resulting escrowed cipher text and use its private key to decrypt and retrieve the escrowed secret.
When the user is well know to the escrow agent, the process for retrieving the secret information is relatively straightforward. The known user presents the escrowed information (possibly including the entire computer) to the trustee, who then retrieves the escrowed information with the trustee's private key (the other half of the public/private key pair) associated with the trustee's encrypting public key) to decrypt the user's secret information. The user may be provided with a program to extract the escrowed information to be forwarded to the trustee. If only the trustee has access to the decrypting private key, the escrowed information is not compromised by the storage of the escrowed information in the user's computer.
The present invention addresses the danger that the trustee might be tricked into revealing escrowed information to someone other than the legitimate owner (or another party entitled to receive the escrowed information). For example, a thief could present a stolen computer to the trustee claiming that it is their own.
In practice, it is not unusual for vendors of computer data encryption products to be asked to help users who claim to have forgotten or otherwise lost their password. Contrary to whatever warnings are offered, users expect vendors to help recover their stored information. If a vendor cannot or will not assist a user due, for example, to fear of liability for revealing sensitive information to a thief, a bona fide user will typically become irate. The risk to the vendor is that the alleged user may not actually be the true owner of the sensitive data but rather an adversary of the true owner--e.g., someone to whom giving access to the computer could potentially severely harm the true owner. Accordingly, the vendor may be faced with the dilemma of whether or not to assist in "re-enabling" a lost key for an often frantic customer.
In accordance with the present invention, various alternative binary data strings may be escrowed. A password used to derive a symmetric DES key which is used to encrypt the user's secret may be escrowed. In its broadest sense, the present invention contemplates escrowing any secret digital information voluntarily placed in the hands of an escrow agent (e.g., a Swiss bank account number, safety deposit identifying indicia, vault combination, the formula for Coca Cola.RTM. or the like). The present invention permits a user to cryptographically secure such data and to securely permit a manufacturer, vendor, or other escrow agent's (trustee) to allow the user to access data under circumstances where the password is forgotten or lost.
The present invention is designed to reduce, if not eliminate, the risk of a trustee escrow agent's (e.g., vendor) possible inadvertent betrayal while balancing the escrow agent's goal of providing security, with optional recoverability--even when the true owner/customer was previously unknown to the vendor. The present invention provides significant assurance to both user and trustee that the trust delegated will not be betrayed if the trustee assists in re-enabling a lost key or password.
The present invention accomplishes these objectives utilizing methodology employing a voluntary identification/definition phase performed, for example, shortly after a computer is purchased, and a secret information retrieval phase. In the definition phase, the true owner/customer defines an escrow record which provides self-identification data together with encrypted password or other secret data. The present invention contemplates prompting a user to voluntarily escrow password or other secret information for later retrieval by entering a series of information uniquely describing himself or herself. The identification indicia is combined with the secret information (such as the user's encryption password) and is then encrypted under the control of the trustee's public key. There are many ways of doing this, and the examples herein are demonstrative and not exhaustive. For example, the combined information may be encrypted, for example, under a random symmetric key (such as DES) which is then encrypted under the trustee's public key.
In an embodiment of the invention, after unique identification data has been entered, the user is asked to select a password to protect the system. Thereafter, all the personal identifying data, together with the password, is encrypted with the manufacturer's (trustee's) public key and is stored, for example, in the user's computer as an escrow security record. The password is then used to encrypt all data on the user's disk.
If at some point in time in the future, the user forgets the password, the retrieval phase of the applicant's invention is performed. Under such circumstances, the user contacts the escrow agent, e.g., the vendor or manufacturer. In accordance with one embodiment of the invention, the user (applicant) must provide sufficient credentials to definitively establish his or her identification. This might take the form of an affidavit executed before a notary public. It might occur by using a digitally signed message verifiable with a well certified public key (or the public key indicated in the escrowed information itself). It might require production of a driver's license, independent investigation by the trustee; or the physical presence of the applicant to confirm identity. In accordance with one embodiment of the present invention, the user in initially establishing the escrow record is asked to define for the vendor what security measures are to be required if the key (or other secret information) must sometimes be retrieved, such as, by requiring identification performed before a notary, a personal appearance, production of a valid driver's license, etc. This allows the true owner to stipulate recovery procedures.
In order to retrieve the escrowed secret, the trustee(s) must have both the encrypted escrowed information as well as the user's credentials. The order in which these are presented to the trustee can vary depending upon the specific embodiment. For example, in the model in which the trustee (or some other third party) stores the escrowed information, one presumes that it is easy for the user to extract the escrowed information (say at the time it was created) and transmit it to the trustee. In another model, such as where the trustee is a vendor providing the key-recovery service, it may be preferred that the user can only extract the escrowed ciphertext with the help of a utility provided by the vendor (at an applicant's request). This utility might be provided to the applicant only after confirming the applicant's identity (even before it is matched with the escrowed identification). In the extreme model, one might even require that the trustee be given physical access (or even possession) of the equipment before extracting the key. This latter requirement could facilitate the return by the trustee of the equipment to its rightful owner. Once the trustee acquires the escrow record, the trustee then decrypts the escrow information and compares the applicant's credentials with the identification stipulated by the true owner of the escrowed information. The trustee utilizes the documentary evidence presented by the alleged legitimate user and determines whether such evidence matches the previously encrypted escrow information stored in the escrow record created by the user. If they agree, then the trustee has confidence that the true owner is making the request, and that revealing the secret key will not betray the owner's interest and subject the trustee to possible legal action.
It may be that the applicant's credentials are ambiguous--in that they (seem to) confirm the applicant, but not to the level of certainty required--falling below the level of proof required by the trustee, or perhaps not meeting all demands initially set or demanded by the true owner at the time the secret and identification was escrowed.
If the two fail to match, then the trustee can take whatever action seems appropriate, including locating the true owner based on the identification embodied in the escrowed information and informing him of the attempted impersonation; attempting to obtain the apparently stolen computer with the intent of returning it to the true owner; informing the police or other authorities of the suspected crime; or determining that the applicant, while not the true owner, may actually have the right to valid access (perhaps by virtue of being the employer). In this case, the applicant would have so advised the trustee and presented sufficient additional credentials.
Different embodiments may determine which, if any, of the various identification facts may appear in the escrowed information outside of the encrypted portion, and how much with the encrypted portion. It may be desirable to encrypt all of the identifying information. This way, an attacker will have fewer clues with which to attempt impersonation. On the other hand, if some of the (more innocuous) information were stored in the escrow record in cleartext, then this could enable a good Samaritan to know the equipment's rightful owner in case of loss.
The above and other features and advantages of the invention and the manner of realizing them will become more apparent and the invention itself will be better understood from a study of the following detailed description and the appended claims with references to the attached drawings showing some exemplary embodiments of the invention.